feat: add rpc filter for early rejection of configured method-param t… - #64

This reuses -32601, which is JSON-RPC's "Method not found" and the same code the server already returns for genuinely-unknown methods (the fallback arm in dispatch, and tests/mod.rs asserts code == -32601). So a client keying on the code can't tell a blocked (method, params) from a method that doesn't exist. Only the message text and the HTTP status differ.

The repo already handles this exact shape (method is valid, a specific param value is rejected by server policy): the commitment=processed rejection in signatures.rs and blocks.rs returns -32602 "Only confirmed or finalized commitments are supported" with data: {requestedCommitment}. Could the filter match that, -32602 + data describing the matched method/params, or take a dedicated code in the -32000..-32099 server range if it should read as "server-imposed"?

This sets 405 unconditionally. Everywhere else the server treats HTTP error statuses as opt-in via emit_http_errors (default false means everything is HTTP 200; only four server-side codes ever promote, to 503). The README's "HTTP status behavior" section says it directly: "Client, malformed-request, and data-condition errors remain HTTP 200 OK." A filtered request is a client error by that taxonomy but returns 405 regardless of the flag, so that section and the filter section now disagree.

Should the 405 be gated behind emit_http_errors (200 by default, like every other client error) so the "HTTP errors are opt-in" contract holds? If the 405 is intentional for ops visibility, maybe a one-line exception in the HTTP-status section so the two don't read as contradictory.

One filtered item sets the whole batch's HTTP status to 405, while response_values still carries every other item's successful result. A client that checks resp.ok before parsing (the exact client the opt-in 503 mechanism exists for) treats the succeeded siblings as failed and may drop or retry the whole batch. JSON-RPC models a batch as N independent responses, so one administratively blocked item escalating the transport status for all of them is a sharp edge, and unlike the 503 batch-promotion it isn't gated by emit_http_errors.

Related: if emit_http_errors is on and a batch has both a filtered item and a 503-eligible error, promote_http_status_for_json_rpc_errors overwrites this 405 with 503 unconditionally, so the documented "returns 405" doesn't hold in that combo.

config is Option<PathBuf> passed straight to load() with no empty guard, and clap turns SUPERBANK_CONFIG="" (or --config "") into Some("") (checked on 4.6.0). So an empty placeholder reads "" and fails boot instead of no-op'ing as "unset." The other optional path flags guard this (disk_cache_path, dragonsmouth_endpoint use .map(str::trim).filter(|v| !v.is_empty())). Same idea here:

RpcParameterFilterSet::load(
    args.config.as_deref().filter(|p| !p.as_os_str().is_empty()),
)

Small one: the loader validates method.trim().is_empty() but then stores the untrimmed method as the key. A quoted entry with a stray space (["getThing ", ...]) passes validation, counts in len(), and logs as loaded, but never matches, since matches compares the raw request method. Narrow case (unquoted YAML strips the space), but it's a silent no-op that slips past the loader's otherwise fail-loud validation. Trimming before storing, or rejecting a non-trimmed method like the empty case, keeps it fail-loud.